Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix(cmd-api-server): stop changing LoggerProvider log level #3362

Merged
merged 1 commit into from
Jul 1, 2024
Merged

fix(cmd-api-server): stop changing LoggerProvider log level #3362

merged 1 commit into from
Jul 1, 2024

Conversation

petermetz
Copy link
Contributor

  1. The API server was mutating global shared state in it's own constructor
    which was causing problems with other components (pretty much all of them)
  2. I deleted the line that copies the API server's own log level to the
    LoggerProvider so that the API server's log level can be it's own.
  3. The way this bug came about is that in the supply chain app example
    in the back-end the API server had to be muted (log level WARN) in order
    for it to stop printing misleading logs due to us binding to the wildcard
    host it would claim in its own logs that the WWW GUI is accessible on the
    wildcard host in a web browser, but this was wrong and caused many people
    a lot of confusion unfortunately.
  4. The fix for the supply chain app is to set the API server's log level to
    WARN and have the supply chain app itself log the correct URLs to the console.
  5. The issue I ran into with that fix is that as soon as I set the log level
    of the API server to WARN, everything else also stopped logging which resulted
    in my fix making everything worse since now the users had absolutely no
    idea what was happening or if the example application had even finished booting
    up or not.
  6. Upon further debugging I discovered that the API server was forcing its
    own log level onto everybody else as the root cause.
  7. A follow-up PR is about to drop with the supply chain app fixes which are
    dependent on this one making it in first.

Signed-off-by: Peter Somogyvari [email protected]

Pull Request Requirements

  • Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
  • Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
  • Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

  • Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
  • Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

@petermetz petermetz enabled auto-merge (rebase) June 26, 2024 20:09
petermetz added a commit to petermetz/cacti that referenced this pull request Jun 27, 2024
@petermetz
docs(examples/supply-chain-app): print correct web host in the CLI logs
f79f8ee 
1. The logs were showing the bound host which in our case was 0.0.0.0
but that is not accepted by web browsers when you are executing HTTP XHR
requests from Javascript.
2. This change makes it so that even though we bind to 0.0.0.0 the logs
to the person running the example application will show 127.0.0.1.
This might potentially cause further confusion in some people who'd think
that we are binding to 127.0.0.1 based on the logs, but this seems like an
acceptable trade-off for an example which has the number one priority of
being easily digestable.

Fixes hyperledger-cacti#2390

Depends on hyperledger-cacti#3362

Signed-off-by: Peter Somogyvari <[email protected]>
@petermetz petermetz mentioned this pull request Jun 27, 2024
Merged
5 tasks
petermetz added a commit to petermetz/cacti that referenced this pull request Jun 27, 2024
@petermetz
docs(examples/supply-chain-app): print correct web host in the CLI logs
fefd726 
1. The logs were showing the bound host which in our case was 0.0.0.0
but that is not accepted by web browsers when you are executing HTTP XHR
requests from Javascript.
2. This change makes it so that even though we bind to 0.0.0.0 the logs
to the person running the example application will show 127.0.0.1.
This might potentially cause further confusion in some people who'd think
that we are binding to 127.0.0.1 based on the logs, but this seems like an
acceptable trade-off for an example which has the number one priority of
being easily digestable.

Fixes hyperledger-cacti#2390

Depends on hyperledger-cacti#3362

Signed-off-by: Peter Somogyvari <[email protected]>
@petermetz
fix(cmd-api-server): stop changing LoggerProvider log level
bb7b7a9 
1. The API server was mutating global shared state in it's own constructor
which was causing problems with other components (pretty much all of them)
2. I deleted the line that copies the API server's own log level to the
LoggerProvider so that the API server's log level can be it's own.
3. The way this bug came about is that in the supply chain app example
in the back-end the API server had to be muted (log level WARN) in order
for it to stop printing misleading logs due to us binding to the wildcard
host it would claim in its own logs that the WWW GUI is accessible on the
wildcard host in a web browser, but this was wrong and caused many people
a lot of confusion unfortunately.
4. The fix for the supply chain app is to set the API server's log level to
WARN and have the supply chain app itself log the correct URLs to the console.
5. The issue I ran into with that fix is that as soon as I set the log level
of the API server to WARN, everything else also stopped logging which resulted
in my fix making everything worse since now the users had absolutely no
idea what was happening or if the example application had even finished booting
up or not.
6. Upon further debugging I discovered that the API server was forcing its
own log level onto everybody else as the root cause.
7. A follow-up PR is about to drop with the supply chain app fixes which are
dependent on this one making it in first.

Signed-off-by: Peter Somogyvari <[email protected]>
@petermetz petermetz force-pushed the fix-cmd-api-server-global-log-level-override branch from e267907 to bb7b7a9 Compare July 1, 2024 16:34
@petermetz petermetz merged commit 6ef514c into hyperledger-cacti:main Jul 1, 2024
148 of 151 checks passed
petermetz added a commit to petermetz/cacti that referenced this pull request Jul 1, 2024
@petermetz
docs(examples/supply-chain-app): print correct web host in the CLI logs
7bac569 
1. The logs were showing the bound host which in our case was 0.0.0.0
but that is not accepted by web browsers when you are executing HTTP XHR
requests from Javascript.
2. This change makes it so that even though we bind to 0.0.0.0 the logs
to the person running the example application will show 127.0.0.1.
This might potentially cause further confusion in some people who'd think
that we are binding to 127.0.0.1 based on the logs, but this seems like an
acceptable trade-off for an example which has the number one priority of
being easily digestable.

Fixes hyperledger-cacti#2390

Depends on hyperledger-cacti#3362

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit that referenced this pull request Jul 1, 2024
@petermetz
docs(examples/supply-chain-app): print correct web host in the CLI logs
fa190ed 
1. The logs were showing the bound host which in our case was 0.0.0.0
but that is not accepted by web browsers when you are executing HTTP XHR
requests from Javascript.
2. This change makes it so that even though we bind to 0.0.0.0 the logs
to the person running the example application will show 127.0.0.1.
This might potentially cause further confusion in some people who'd think
that we are binding to 127.0.0.1 based on the logs, but this seems like an
acceptable trade-off for an example which has the number one priority of
being easily digestable.

Fixes #2390

Depends on #3362

Signed-off-by: Peter Somogyvari <[email protected]>
@petermetz petermetz deleted the fix-cmd-api-server-global-log-level-override branch July 1, 2024 17:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jagpreetsinghsasan jagpreetsinghsasan jagpreetsinghsasan approved these changes

@outSH outSH outSH approved these changes

@takeutak takeutak Awaiting requested review from takeutak takeutak is a code owner

@izuru0 izuru0 Awaiting requested review from izuru0 izuru0 is a code owner

@VRamakrishna VRamakrishna Awaiting requested review from VRamakrishna VRamakrishna is a code owner

@sandeepnRES sandeepnRES Awaiting requested review from sandeepnRES sandeepnRES is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@petermetz @outSH @jagpreetsinghsasan